A few months ago, I came across a Hacker News discussion and they were sharing what resources they used for learning tech and keeping up with the industry. One person recommended the Pragmatic Engineer newsletter, so I signed up for the weekly free one.

A few weeks ago they published an article about measuring developer productivity, something I, and many others, have struggled with for a long time. It is very hard to measure this, as nearly any metric you can come up with will be optimized for by the developers, but not necessarily add any actual value while doing so (and frequently will actually hurt productivity). Of course, board members and fellow executives don’t like hearing that, as other groups are relatively easy to measure.

Anyway, the article is fantastic, and I highly recommend reading it. After going through part 1 and part 2, I subscribed to the paid version of the newsletter – this is really good stuff.

Part 1:
https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity

Part 2:
https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity-part-2

In Part 1 there is a reference to measuring certain development metrics and the impact it had on behavior (it was not the desired impact!). When stuff like this comes up, I always bust out this comic the Dilbert comic where an announcement is made that the company is going to pay a bonus for each bug found and fixed, and Wally immediately says he’s going to write himself a minivan this afternoon (I would post a link to it, but Scott Adams has taken Dilbert private). You can find copies of it by searching for Dilbert Minivan.


Great blurb in Part 2:
Understand what the real need is. When someone asks how to measure developer productivity, it is never the true question. To discern what’s really being asked, consider these things: who is asking, and what is their real goal? The real topic will be something like:

“I need to decide which areas to invest more headcount in. Which allocation will give the business the best return?”
“I want to do performance management and identify low and high performers.”
“I want to pinpoint problematic teams, debug and fix them.”
“Our investors want us to reduce costs and I need to figure out how much I can cut without significantly impacting the business.”
“I need to justify the cost of engineering to the CEO who thinks we’re too expensive.”


There is another response at : https://tidyfirst.substack.com/p/measuring-developer-productivity-440

The part that matters in that one is headlined: How do you decide how much to invest in engineering?

Combined it’s a lot of reading, but very valuable if you need to justify how hard it is to justify just how productive your engineering resources are being, or maybe rethink some things you’ve already put in place.